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Abstract 


This document describes how the Elliptic Curve Digital Signature 
Algorithm (ECDSA) may be used as the authentication method within the 
Internet Key Exchange (IKE) and Internet Key Exchange version 2 
(IKEv2) protocols. ECDSA may provide benefits including 
computational efficiency, small signature sizes, and minimal 
bandwidth compared to other available digital signature methods. 

This document adds ECDSA capability to IKE and IKEv2 without 
introducing any changes to existing IKE operation. 
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Les 


Introduction 


The Internet Key Exchange, or IKE [IKE], is a key agreement and 
security negotiation protocol; it is used for key establishment in 
IPsec. In the initial set of exchanges, both parties must 
authenticate each other using a negotiated authentication method. In 
the original version of IKE, this occurs in Phase 1; in IKEv2, it 
occurs in the exchange called IKE-AUTH. One option for the 
authentication method is digital signatures using public key 
cryptography. Currently, there are two digital signature methods 
defined for use within Phase 1 and IKE-AUTH: RSA signatures and 
Digital Signature Algorithm (DSA) Digital Signature Standard (DSS) 
Signatures. This document introduces ECDSA signatures as a third 
method. 


For any given level of security against the best attacks known, ECDSA 
signatures are smaller than RSA signatures, and ECDSA keys require 
less bandwidth than DSA keys [LV]; there are also advantages of 
computational speed and efficiency in many settings. Additional 
efficiency may be gained by simultaneously using ECDSA for IKE/IKEv2 
authentication and using elliptic curve groups for the IKE/IKEv2 key 
exchange. Implementers of IPsec and IKE/IKEv2 may therefore find it 
desirable to use ECDSA as the Phase 1/IKE-AUTH authentication method. 


Requirements Terminology 


The key word "SHALL" in this document is to be interpreted as 
described in [RFC2119]. 


ECDSA 


The Elliptic Curve Digital Signature Algorithm (ECDSA) is the 
elliptic curve analogue of the DSA (DSS) signature method [DSS]. It 
is defined in the ANSI X9.62 standard [X9.62-2003]. Other compatible 
specifications include FIPS 186-2 [DSS], IEEE 1363 [IEEE-1363], IEEE 
1363A [IEEE-1363A], and SEC1 [SEC]. 


ECDSA signatures are smaller than RSA signatures of similar 
cryptographic strength. ECDSA public keys (and certificates) are 
smaller than similar strength DSA keys, resulting in improved 
communications efficiency. Furthermore, on many platforms, ECDSA 
operations can be computed more quickly than similar strength RSA or 
DSA operations (see [LV] for a security analysis of key sizes across 
public key algorithms). These advantages of signature size, 
bandwidth, and computational efficiency may make ECDSA an attractive 
choice for many IKE and IKEv2 implementations. 
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4. 


Specifying ECDSA within IKE and IKEv2 


The original IKE key negotiation protocol consists of two phases, 
Phase 1 and Phase 2. Within Phase 1, the two negotiating parties 
authenticate each other using either pre-shared keys, digital 
signatures, or public key encryption. 


The IKEv2 key negotiation protocol begins with two exchanges, 
IKE-SA-INIT and IKE-AUTH. When not using extensible authentication, 
the IKE-AUTH exchange includes a digital signature or Message 
Authentication Code (MAC) on a block of data. 


The IANA-assigned attribute number for authentication using generic 
ECDSA in IKE is 8 (see [IANA-IKE]), but the corresponding list of 
IKEv2 authentication methods does not include ECDSA (see 


[IANA-IKEv2]). Moreover, ECDSA cannot be specified for IKEv2 
independently of an associated hash function since IKEv2 does not 
have a transform type for hash functions. For this reason, it is 


necessary to specify the hash function as part of the signature 
algorithm. Furthermore, the elliptic curve group must be specified 
since the choice of hash function depends on it as well. Asa 
result, it is necessary to specify three signature algorithms, named 
ECDSA-256, ECDSA-384, and ECDSA-521. Each of these algorithms 
represents an instantiation of the ECDSA algorithm using a particular 
elliptic curve group and hash function. The three hash functions are 
specified in [SHS]. For reasons of consistency, this document 
defines the signatures for IKE in the same way. 


Digital 

Signature 
Algorithm Elliptic Curve Group Hash Function 
ECDSA-256 256-bit random ECP group SHA-256 
ECDSA-384 384-bit random ECP group SHA-384 
ECDSA-521 521-bit random ECP group SHA-512 


The elliptic curve groups, including their base points, are specified 
in [IKE-ECP]. 


Security Considerations 


Since this document proposes new digital signatures for use within 
IKE and IKEv2, many of the security considerations contained within 
[IKE] and [IKEv2] apply here as well. Implementers should ensure 
that appropriate security measures are in place when they deploy 
ECDSA within IKE or IKEv2. 
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and ECDSA-521 are designed to offer security 


AES-192, 


ES-256 respectively. 


and ECDSA-521. 


or ECDSA-521 is used as the digital 
the signature payload SHALL contain an 


The definitions of r and s are given in 


Bit Length 


of Signature 


necessary, by pre-pending 


6. IANA Considerations 
IANA updated its registry of IPsec authentication methods in 
[IANA-IKE] and its registry of IKEv2 authentication methods in 
[IANA-IKEv2] to include ECDSA-256, ECDSA-384, 
7. ECDSA Data Formats 
When ECDSA-256, ECDSA-384, 
signature in IKE or IKEv2, 
encoding of the computed signature consisting of the concatenation of 
a pair of integers r and s. 
Section 8 of this document. 
Digital 
Signature Bit Lengths 
Algorithm of r and s 
ECDSA-256 256 
ECDSA-384 384 
ECDSA-521 528 
The bit lengths of r and s are enforced, if 
the value with zeros. 
8. Test Vectors 


The following are examples of the IKEv2 authentication payload for 
each of the three signatures specified in this document. 


The following notation is use 
the elliptic curve y^2 (x^3 
point on the curve (i.e., 


n; it is another point on the 


multiple is typically denoted n (x,y); 


conform to the notation used 


The group order for the curve group is denoted q. 
The hash of the message is denoted h. 
it is an integer between 


denoted g= (gx, gy). 
signer’s static private key i 
zero and q. 


ephemeral private key is denoted k; 
The ephemeral public key is g*k=(gkx,gky) . 
the integer between zero and q such that k*kinv 


q. 
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d. 


3 x + b) 


The Diffie- 
modulo p. 
x and y satisfy the above equation), 
(x,y)^n denotes the scalar multiple of the point 


Hellman group is given by 
If (x,y) is a 
then 


(x,y) by the integer 


curve. 


in [IKE], 


s denoted w; 


The signer’s static public key is g*w=(gwx,gwy). 
it is an integer between zero and 


Standards Track 


In the literature, 
the notation 
[IKEv2], 


the scalar 
(x,y) *n is used to 
and [IKE-ECP]. 


The generator is 
The 


The 


The quantity kinv is 
1 modulo q. The 


[Page 4] 


RFC 4754 IKE and IKEv2 Authentication Using ECDSA January 2007 


Sr. 


P 


b 


q: 


gx: 


first signature component is denoted r; it is equal to gkx reduced 
modulo q. The second signature component is denoted s; it is equal 
to (htr*w)*kinv reduced modulo q. 


The test vectors below also include the data for verifying the ECDSA 
signature. The verifier computes h and the quantity sinv, which is 
the integer between zero and q such that s*sinv = 1 modulo q. The 
verifier computes 


u = h*sinv modulo q 
and 
v = r*sinv modulo q. 
The verifier computes (gx,gy)*u = (gux,guy) and (gwx,gwy)“v = 
(gwvx,gwvy). The verifier computes the sum 
(sumx, sumy) = (gux,guy) + (gwvx,gwvy) 
where + denotes addition of points on the elliptic curve. The 


signature is verified if 
sumx modulo q = r. 
ECDSA-256 
IANA assigned the ID value 9 to ECDSA-256. 


The parameters for the group for this signature are 


FFFFFFFF 00000001 00000000 00000000 00000000 FFFFFFFF FFFFFFFF FFFFFFFF 


5AC635D8 AA3A93E7 B3EBBD55 769886BC 651D06B0 CC53BOF6 3BCE3C3E 27D2604B 


FFFFFFFF 00000000 FFFFFFFF FFFFFFFE BCE6FAAD A7179E84 F3B9CAC2 FC632551 


6B17D1F2 E12C4247 F8BCE6E5 63A440F2 77037D81 2DEB33A0 F4A13945 D898C296 


gy: 


4FE342E2 FE1A7F9B 8EE7EB4A 7COF9E16 2BCE3357 6B315ECE CBB64068 37BF51F5 


Fu 
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The static and ephemeral keys are given by 


wW 


DC51D386 6A15BACD E33D96F9 92FCA99D A7E6EF09 


gwx: 


2442A5CC OECDO15F A3CA31DC 8E2BBC70 BF42D60C 


gwy: 


6FC98BD7 E50211A4 A27102FA 3549DF79 EBCB4BF2 


k 


9E56F509 196784D9 63D1C0A4 01510EE7 ADA3DCC5 


gkx: 


CB28E099 9B9C7715 FDOA80D8 E47A7707 9716CBBF 


gky: 


2B57C023 5FB74897 68D058FF 4911C20F DBE71E36 


The SHA-256 hash of the message "abc" (hex 
h: 


BA7816BF 8FO1CFEA 414140DE 5DAE2223 BO0361A3 


The signature of the message is (r,s) 


kinv: 
AFA27894 5AF74B1E 295008E0 3A8984E2 E1C69D9B 


Ë: 
CB28E099 9B9C7715 FDOA80D8 E47A7707 9716CBBF 


S: 
86FA3BB4 E26CAD5B F90B7F81 899256CE 7594BB1E 


The quantities required for verification of 


sinv: 
33BDC294 E90CFAD6 2A9F2FD1 F8741DA7 7C02A573 


ur 
C3875E57 C85038A0 D60370A8 7505200D C8317C8C 


v: 
3B4E49C4 FDBFC006 FF993C81 A50EAE22 1149076D 
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where 


34E70975 59C27F16 


BCA20085 E0822CB0 


46B80945 CDDFE7D5 


DEE04B15 4BF61AF1 


917DD72E 97566EA1 


99D91339 AFBB903E 


616263) is 


96177A9C B410FF61 


BBC74AF1 4E3AC4E4 


917DD72E 97566EA1 


A0C89212 748BFF3B 


the signature are 


E1B53BA1 7A60BA90 


534948BE A6559C7C 


6ECO9DDD 9FB3B787 
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14C88A7F 


4235E970 


0 9BBFD7D 


D5A6DECE 


CO66957C 


E17255DC 


F20015AD 


21ABFA61 


CO66957C 


3D5B0315 


4F491952 


18E6D4CE 


F85B6483 
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gux: 
4F 749762 


guy: 
8490E12D 


IK] 


9362EFBB 


E4DBB68C 


EE591206 


BF941721 


gwvx: 
726E5684 


gwvy: 
OC1OCBA8 


sumx: 
CB28E099 


sumy: 


964DB8EA 


DD2620C1 


9B9CT715 


341D8679 


12A4F 9BE 


D036568F 


5D8C648E 


23978 9B2 


57A8E0E4 
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34960635 


4E176856 


DFB70E04 


EDA404E9 


578E4BE1 


E64DCOF7 


FDOA80D8 


E47A7707 


2B57C023 5FB74897 68DO058FF 4911C20F 


The signature is valid since sumx 


If the signature 


(r,s) 


971 6CBBF 


DBE71E36 


modulo q 


94BA730F 


D1D526CA 


917DD72E 


99D91339 


equals r. 


payload, then the payload would be as follows. 


00000048 00090000 C 
97566EA1 C066957C 86FA3 


748BFF3B 


82a 


IANA assigned the ID value 10 to ECDSA-384. 


3D5B0315 


ECDSA-384 


B28E099 9B9C7715 FD0A80D8 E47A7707 
BB4 E26CAD5B F90B7F81 899256CE 


The parameters for the group for this signature are 


p: 
FFFFFFFF 


FFFFFFFF 


D: 
B3312FA7 
C656398D 


q: 
FFFFFFFF 
581A0DB2 


FFFFFFFF 
00000000 


E23EE7E4 


FFFFFFFF 
00000000 


988E056B 


FFFFFFFF FFFFFFFF FFFFFFFF 


FFFFFFFF 


8A2ED19D 


FFFFFFFF 


48BOA77A ECEC196A 
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2A85C8ED 


FFFFFFFF 


D3EC2AEF 


E3F82D19 181D9C6E FE814112 


FFFFFFFF FFFFFFFF FFFFFFFF 


CCC52973 
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C6607EC6 


3CD58697 


A43F1E78 


167749F9 


97566EA1 


AFBB903E 


971 6CBBF 
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99062600 


001A8D08 


ED81211B 


CECODF08 


CO66957C 


E17255DC 


were the one appearing in the authentication 


917DD72E 


7594BB1E A0C89212 


FFFFFFFF 


0314088F 


C7634D81 


FFFFFFFE 


5013875A 


F4372DDF 
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gx: 


IK] 


$ 
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AA87CA22 BE8B0537 8EB1C71E F320AD74 6E1D3B62 8BA79B98 59F741E0 
5502F25D BF55296C 3A545E38 72760AB7 
gy: 
3617DE4A 96262C6F 5D9E98BF 9292DC29 F8F41DBD 289A147C E9DA3113 
OA60B1CE 1D7E819D 7A431D7C 90EAOESF 
The static and ephemeral keys are given by 
w: 
OBEB6466 34BA8773 5D77AE48 09AQEBEA 865535DE 4C1E1DCB 692E8470 
62E528C3 8B2A81B3 5309668D 73524D9F 
gwx: 
96281BF8 DD5E0525 CA049C04 8D345D30 82968D10 FEDF5C5A CA0C64E6 
5CE10C9D FEC21797 41571072 1F437922 
gwy: 
447688BA 94708EB6 E2E4D59F 6AB6D7ED FF9301D2 49FE49C3 3096655F 
3D383B91 C5E7EDAA 2B714CC9 9D5743CA 
k: 
B4B74E44 D71A13D5 68003D74 89908D56 4C7761E2 29C58CBF A1895009 
854D7FA9 92F934D9 27376285 E63414FA 
gkx: 
FBO17B91 4E291494 32D8BAC2 9A514640 B46F53DD AB2C6994 8084E293 
O8EO7C9C 63F2D21A O07DCB56A 6AF56EB3 
gky: 
20735822 48686C41 8485E7B7 4E707625 A1832769 FUF56E81 7CF83B1E 
65B7AD37 BC2F865F DC290DB6 15CDF17F 
The SHA-384 hash of the message "abc" (hex 616263) is 
h: 


CB00753F 45A35E8B B5A03D69 9AC65007 272C32AB 


8086072B Al 


The signature of the message is 


kinv: 


E7CC23 58BAECA1 34C825A7 


(r,s) 


where 


OEDED163 1A8B605A 


EB12876B F6191A29 1AA5780A 3887C3BF E7A5C7E3 21CCA674 886B1228 
918EF19F E5CE67E9 80BEDC1E 613D39C0 
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82542A38 


BSFOB8CO 


8E81A5AF 


465A97EA 


5D502FAD 


6EB7463B 


OF1C8F7E 


4690E782 


43FF5BED 


D9BB3D52 
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ie 


IK] 
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O8EO7C9C 63F2D21A 07DCB56A 6AF56EB3 


S 


CBB9F516 CEOFA7D2 FF630863 A00E8B9F 


The quantities required for verification of the signature are 


sinv: 
O6EFACEE 
6ADD7D3B 


u: 
CA5E3714 
7D731721 


v: 
1342C935 
69E75EF9 


gux: 
94B90657 
E544EB10 


guy: 
45882DC2 
87E9953A 


gwvx: 
6A142FF2 
0811C3B8 


gwvy: 
98C2A76C 
173F1ABF 


sumx: 
FB017B91 
08E07C9C 


sumy: 
2C735822 
65B7AD37 


8A657E77 
9O0R1CDA4 


B4B68BB8 
ABE62CCO 


5F1A4563 
06DA2396 


77A3B5BE 
TD35F7C9 


CF367F74 
CC634CEF 


BOB8C552 
41B34CA6 


7E6EDB56 
F3980DF1 


4E291494 
63F2D21A 


48686C41 
BC2F865F 
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584C5A03 
79BD899B 


5SAFOBC69 
1165ABFD 


5435899A 
2C747C04 


399CEE66 
3FA8FB11 


3FC02961 
2D9897B8 


9B7F78E2 
E1785BC8 


6B1DB657 
F7EC4335 


32D8BAC2 
O7DCB56A 


8485E7B7 
DC290DB6 


9F7E2720 
EE14B99D 


E12B16C8 
847088E9 


C24AEF06 
A01137B8 


A9SDB4E64 
8DCB91ED 


2D5B96FC 
BEE32BC2 


1B014764 
DB9111F4 


ED3019F8 
B185CEBF 


9A514640 
6AF56EB3 


4E707625 
15CDF17F 


D61DF84C 


8FAFA26A 


3947CA47 


8422E370 


F9A09E28 


440ED8CO 


2FB94FBB 


B46F53DD 


A1832769 
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8FAC6FA4 


A6598D7E 


951E89F6 


F19ED1A9 


1C3C162D 


339B2187 


F36124DE 


9AD6F 6C4 


2D5C3C40 


83D73172 


C699769E 


0D189267 


13DB9500 


C23BB7DE 
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FBO17B91 4E291494 32D8BAC2 9A514640 B46F53DD AB2C6994 8084E293 OFIC8F7E 


B263A130 5E057F98 4D38726A 1B468741 O9F417BC A112674C 528262A4 OA629AF1 


6E8CDA28 


26F7A944 


F964C359 


O01EC9A30 


83841606 


3D1A8BA5 


4B181357 


AB2C6994 


F7F56E81 


8084E293 


7CF83B1E 


OF1C8F7E 


4690E782 
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The signature is valid since sumx modulo q equals r. 


If the signature (r,s) were the one appearing in the authentication 
payload, then the payload would be as follows. 


00000068 OO0A0000 FBO17B91 4H291494 32D8BAC2 9A514640 
8084E293 OFIC8F7E O8E07C9C 63F2D21A O7DCB56A 6AF56EB3 
4D38726A 1B468741 O09F417BC A112674C 528262A4 OA629AF1 
FF630863 AOOE8B9F 


B46F53DD AB2C6994 
B263A130 5E057F98 
CBB9F516 CEOFA7D2 


8.3. ECDSA-521 


IANA assigned the ID value 11 to ECDSA-521. 


The parameters for the group for this signature are 


p: 
O1FFFFFE 
FFFFFFFF 
FFFF 


b: 
0051953E 
09F15619 
3F00 


q: 
O1LFFFFFF 
FFFA5186 
6409 


gx: 
00C6858E 
3DBAA14B 
BD66 


gy: 
01183929 
662C97EE 
6650 


FFFFFFFF 
FFFFFFFF 


B9618E1C 
3951EC7E 


FFFFFFFF 
8783BF2F 


06B70404 
5E77EFE7 


6A789A3B 
72995EF4 


FFFFFFFF 
FFFFFFFF 


9A1F929A 
937B1652 


FFFFFFFF 
966B7FCC 


E9CD9E3E 
5928FE1D 


CO045C8A 
2640C550 


The static and ephemeral 


wW: 


0065FDA3 409451DC ABOAOEAD 


20597779 060A7FF9 D704ADF7 


5FA1 
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FFFFFFFF 
FFFFFFFF 


21A0B685 
COBD3BB1 


FFFFFFFF 
0148F709 


CB662395 
C127A2FF 


5FB42C7D 
B9013FAD 


keys are 


45495112 
8B570FFA 


FFFFFFFF 
FFFFFFFF 


40EEA2DA 
BF073573 


FFFFFFFF 
A5D03BB5 


B4429C64 
A8DE3348 


1BD998F5 
0761353C 


given by 


A3D813C1 
D6F062E9 
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FFFFFFFF 
FFFFFFFF 


725B99B3 
DF883D2C 


FFFFFFFF 
C9B8899C 


8139053F 
B3C1856A 


4449579B 
7086A272 


7BED34BD 
5C7EOCSD 


FFFFFFFF 
FFFFFFFF 


15F3B8B4 
34F1EF45 


FFFFFFFF 
47AEBB6F 


B521F828 
429BF97E 


446817AF 
C24088BE 


F8C1209D 
5481C5B1 


FFFFFFFF 
FFFFFFFF 


89918EF1 
1FD46B50 


FFFFFFFF 
B71E9138 


AF606B4D 
7E31C2E5 


BD17273E 
94769FD1 


TDF58491 
53B48B37 
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Qwx: 
0151518F 
7AFEOA6D 
52A8 


gwy: 
006F3B14 
D9DF45CA 
E643 


k: 
00C1C2B3 
373778F9 
6C2F 


gkx: 
0154FD38 
B19F2F28 
2251 


gky: 
006D073D 
8117B05E 
B437 


IK] 


1AF0F563 
DEB8BEDB 


2EA1BFFF 
D7803C6C 


O5419F5A 
DE6B6497 


36AF92D0 
1A7E0B22 


72B272EA 
B91BA11C 


The hash of the 


SHA-512 (616263) : 


DDAF35A1 
2192992A 


Therefore, 


h 


93617ABA 
274FC1A8 


E and IKEv2 Authentication Using ECDSA 


517EDD54 
CD6A197E 


5 


7E2837AD 
20035B2F 


41344D7E 
B1EF825F 


DCA57DD5 
C269D93C 


86388D86 
68BCFC1B 


message 


" abc " 


85190DF9 
592D4018 


44C9E4FF 
3FF63AFF 


4359933D 
F24F42F9 


341D3053 
F8794A92 


8EF64D4C 
C24587E3 


CC417349 AE204131 
36BA3C23 A3FEEBBD 


the quantity h is 


OOOODDAF 35A19361 7ABACC41 7349AE20 


D39A2192 992A274F C1A836BA 3C23A3FE 


A49F 


SA4BF57B 
8901CECD 


6D2D34C7 
4E1BA64D 


734096F5 
B4A4BD73 


988534FD 
78880ED7 


300A67AC 
A1DOCA2A 


(hex 616263) 


12E6FA4E 
454D4423 


4131126 
EBBD454D 


SCBA4CF2 
650699C9 


3184BBAD 
1C077577 


56197A9B 
82CFC337 


E8318FC6 
DBB8D936 


2981C0F8 
FE398CDB 


is 


8 9A9TEA2 


643CE80E 


FA4E8 9A9 
4423643C 


The signature of the message is (r,s) where 

kinv: 
OOB90EF3 CE52F8D1 ESA4EEBD 0905F425 2400BOAE 73B49E33 
TC45F3A2 DE3A3EA2 E51D9343 46D71593 A80C8C62 FE229DDF 


0D32 
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A9A3F647 
B5E456AE 


90026DD5 
DA3F 4286 


244342B8 
8A540B1B 


AAAAB68E 
2CAEACEE 


E6710AEF 
CFD79CB3 


OAQSEEEER6 
2A9AC94F 


7EA20A9E 


January 2007 


4725A35F 
A5ADD190 


E6E85317 
CS8FOAEA 


B62F46F9 
7F0C1B95 


2E6F4339 
54432055 


A2FCF845 
0B36B218 


4B55D39A 
A54CA49F 


EEE64B55 


E80E2A9A 


23BCE258 
5D2B64B7 


C94FA54C 


A55F507D 
AF4A0837 
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rs 
0154FD38 
B19F2F28 
2251 


s: 
017705A7 
97536710 
2660 


The quantities required for verification of the signature are 


sinv: 
OODDA6B8 
3F6778BD 
78E0 


u: 
019E5FDB 
D74FA657 
32D8 


v: 
0069BB0C 
006E62C4 
BF 03 


gux: 
00921F3E 
144CA24E 
3311 


guy: 
01812CBF 
C29A4220 
B4EB 


gwvx: 
OOAF23A7 
87286BC7 
0688 


gwvy: 
017A32C4 
9D52B745 
A5B3 


IK] 


36AF92D0 DCA57DD5 341D3053 
1A7E0B22 C269D93C F8794A92 


030290D1 CEB605A9 A1BBO3FF 
1F67D1CF 9BCCBF2F 3D239534 


83CB3 6BF 
977D8460 


ECC2A88B 
8A23C85D 


BASA6FC8 
30CE545E 


CEAF579C 
20310DEF 


E8D08BE9 
83E3495E 


TE50CC54 
7AAEBA32 


5A01DF60 
CSATFEC6 


Fu & Solinas 


CB21D5B0 
867853AE 


T 


72679233 
598D1DC6 


8A08COAD 
9C918F04 


FDDA6AF 9 
2F777892 


OCD6AB5D 
D14726A0 


8CEBC506 
4FF675A1 


3CA96FDF 
777BB899 


B7D1F443 
9C74EF5E 


11B27868 
C1DA074E 


AA88F5A5 
D852DA13 


C1728E5B 
DA1ED5DE 


2ED107A0 
9868AF1B 


58FE4A0B 
FF7035B6 


E83493BB 
B65730E9 
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January 2007 


988534FD E8318FC6 AAAABO8E 2E6F4339 
DBB8D936 2CAEACEE 54432055 


78880ED7 


9CDD521E 87A696EC 926C8C10 C8362DF4 
FA509E70 AAC851AE O1AAC68D 62F86647 


9D3C7797 
417CFA96 


42 7AE2B8 
0AB83852 


1EE60477 
47CC6A3E 


CA33F77B 
A9A6EF09 


123A41A9 
399CEF86 


A26FF9DE 
89AF3835 


4CB5EE00 
32D1395D 


Standards Track 


B23A8D73 
F7C937C1 


83ED0346 
BDAAE2F1 


2D084D98 
FA89BC2C 


5S7F5984C 
85D965AE 


C15ACB31 
6DDDE6B1 


4E864DE2 
95F8B5A8 


C32960A5 
CO0574D3C 


58032D5C 
418D9343 


9CBABE65 
857713D3 


63DF86FD 
13B89124 


624BFF10 
98BCF129 


7D65E228 
0D709696 


7FD059B6 
67432FFE 


4FEB0B39 
F1093C64 


C917142E 
738A1BA8 


ACD3F2F8 
5BB9BDB7 


958AD9B3 
25BA8D60 


F244B577 
855C6C4F 


92D89AF8 
06525D15 


3AE14B5F 
8BF29CE6 


88841E2F 
505804D0 
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sumx: 

0154FD38 36AF92D0 DCA57DD5 341D3053 988534FD E8318FC6 AAAAB68E 2E6F4339 
B19F2F28 1A7E0B22 C269D93C F8794A92 78880ED7 DBB8D936 2CAEACEE 54432055 
2254 

sumy: 

006D073D 72B272EA 86388D86 8EF64D4C 300A67AC 2981C0F8 E6710AEF A2FCF845 
8117B05E B91BA11C 68BCFC1B C24587E3 A1DOCA2A FE398CDB CFD79CB3 0B36B218 
B437 

The signature is valid since sumx modulo q equals r. 


If the signature (r,s) were the one appearing in the authentication 
payload, then the payload would be as follows. 


0000008C 
AAAAB68E 
2CAEACEE 
96EC926C 
51AE01AA 


000B0000 
2E6F 4339 
54432055 
8C10C836 
C68D62F8 
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